Design of a Map-Based Transit Itinerary Planner

Geographic Information Systems (GIS) have provided a platform to present information over the Internet to potential users of public transportation. The advantage of using a GIS is that it allows the user to select an origin and destination on a map, easing the task of inputting information to the itinerary-planning process. In addition, the mapping features of GIS can provide a user-specific map showing the route(s) used in the itinerary, as well as local access, egress, and bus stop information. In this article, the design issues associated with the use of GIS in itinerary generation are discussed. Specific design principles are articulated, based on existing knowledge of requirements for the human-computer interface (HCI). In application of these principles, this article describes the implementation of an ArcIMS GIS-based itinerary planner for the Sun Tran bus network in Tucson, Arizona. This system provides users the option of selecting their origin or destination on the map, manually entering an address, or selecting a landmark from a pull-down menu. The routing algorithm then finds the optimum path, and the output is presented to the user both in text and on the map. This is unique from other itinerary planners because it provides an interactive point-and-click map feature that can be implemented using commercially available GIS software. Journal of Public Transportation, Vol. 9, No. 2, 2006 46 Introduction Transit agencies have always struggled to attract riders in a highly competitive transportation market. Potential riders have a large number of options available to them that would encourage use of other modes of transportation. One of the major problems associated with transit ridership is the presentation of information. Abdel-Aty (2001) performed a survey of the effect of advanced transit information and stated, “About 38% of non-transit users indicated that they might consider transit use if appropriate transit information was available to them” (p. 276). Historically, transit agencies offered transit information including trip planning through call centers. One of the limitations of this system is that graphical information was difficult to relay through a telephone call. Recently, transit agencies have made their service information available on the Internet, using maps, schedules, and on-line automated trip planners. The Internet provides certain benefits when presenting information but cannot replace call centers for more complex trip-planning requests or for people without Internet access. Hence, rather than replacing call centers, the Internet can serve some passengers’ routine trip-planning needs, relieving call centers of some of this traditional workload. Radin et al. (2002) provides an excellent report on the current state-of-the-practice of on-line trip planners. There have been several approaches to create on-line trip planners. One of the more advanced applications is the introduction of interactive maps using Geographic Information Systems (GIS) software. This software provides functionality that allows a map to be created and accessed that is personalized to the user’s preferences and route choices. Several researchers have described itinerary-planning systems and have recommended functions and features that should be provided. Trépanier et al. (2002) indicate that the itinerary calculation process includes: • origin, destination, and circumstance specifications, • access and egress calculations, • path calculation, and • schedule integration. When developing a trip planner, the developer must consider the user’s needs and provide tools that allow the user to plan his/her trip using the same decisionmaking factors that he/she would use without the trip planner. Several authors have identified some options that mimic this decision-making process. Huang Design of a Map-Based Transit Itinerary Planner 47 and Peng (2001) note that important trip-planning options should include the shortest travel time, the minimum amount of transfers, the minimum fare, and/or the least amount of walk time. Donovan (1998) recommends allowing the user to choose which mode he/she prefers and allow the user to choose his/her maximum walking time. Trip planners can also provide a large amount of information to developers and planners related to the origins, destinations, and timing of trips, and on the use of the trip planner software. Trépanier et al. (2005) show that people using mapbased trip planners employ a mixture of methods when determining their origins and destinations, including clicking on the map, entering a landmark or intersection, or any combination of those for both the origin and destination. The authors also demonstrate that users often plan more than one trip during their visit to the transit website. These are important considerations when developing an on-line trip planner. Text-Based Trip Planners Many times the input and output of the trip planner is a text-based interface. The user enters his/her address at the origin and destination and time requirements including day of travel in text fields. These time inputs can include the time at the origin or the time at the destination (Huang and Peng 2002). The information is sent to the web server, which sends it to a routing algorithm. The completed itinerary is returned to the web server and back to the browser. This has been the state-of-the-practice of on-line transit itinerary planners since their evolution from call centers (Radin et al. 2002). Peng and Huang (2000) recognize some problems associated with text-based trip planners. One major problem is that, many times, the user either does not know the exact address of both the origin and the destination or the user does not enter the address correctly. Another problem is that sketch maps often do not provide enough detail or scale to be useful when attempting to plan a trip. Peng and Huang state that a solution to this problem is to allow users to pick their origins and destinations from pull-down menus and provide interactive maps during the itinerary-planning process. This is reinforced by a large literature on human-computer interface design (Brinck et al. 2002; Shneiderman 1998). Map-Based Trip Planners To incorporate maps into this process, Smith (2000) identifies the two major functions of a map-based trip planner. The first function is that the planner must make Journal of Public Transportation, Vol. 9, No. 2, 2006 48 spatial decisions. This function requires that a planner find all the nearby transit stops within walking distance of a desired origin or destination. The trip planner must also be able to make temporal decisions; that is, the planner must be able to link schedule times to the origin and destination as well as to determine total trip time and maximum time allowed for the trip. Smith (2000) explained that the goal of a map-based trip planner is to minimize total trip time subject to spatial, temporal, and system constraints. Peng and Huang (2000) indicate that on-line, map-based trip planners have a three-tier architecture. The first tier of the architecture contains a user interface on the web browser, which is the client-server tier. The second tier is a web server, which is the server tier. The third tier is an application server that contains a GIS application server and/or a database server, which is the application tier. As an example of this third tier, Karimi et al. (2004) developed an address geocoding and routing application that finds the route with the minimum number of transfers between an origin and destination and displays them on a GIS-based map. To date, there are very few map-based trip planners in which the user can interact with the map while choosing origins and destinations (Caliper Corporation 2003; STM 2003), particularly those that use commercial off-the-shelf GIS tools. Lee et al. (1999) discuss the challenges of developing a map-based trip planner using commercial off-the-shelf GIS tools. The authors outline data needs and difficulties associated with identifying accurate locations on a map using GIS software. The objective of this research is to develop some general design principles for a GIS-based itinerary-planning tool. To illustrate these principles, the research also implemented a prototype GIS map-based itinerary-planning website for a transit agency, using readily available software. This paper documents the design principles and subsequent development of the prototype website. The second section of the article provides more detail about the design principles for a map-based trip planner. The process of data acquisition and development for such a trip planner are discussed in the third section. The fourth section presents the development of a prototype map-based itinerary planner using ArcIMS and transit schedule information. Finally, the fifth section offers conclusions and recommendations to improve the functionality and performance of such itinerary-planning tools. Design of a Map-Based Transit Itinerary Planner 49 System Design Principles The goal of a map-based itinerary-planning system is to provide the transit rider with an interactive, easy-to-use, trip-planning application on the Internet. This system must be GIS map-based to provide interactivity. Its tools must be intuitive and easy to use, yet it must include powerful GIS functions to perform the analysis. User Interface Properties The user interface serves two different purposes: (1) it provides a common interface by which information is collected from the user as inputs to the itinerary planner; and (2) it provides the interface by which the specific itinerary is communicated back to the user. Both of these purposes require specific considerations on the user interface. When developing the trip planner, one important element in the design is to determine what input from the GIS is needed for the routing algorithm and then decide how to provide the data to the routing algorithm. Most commonly, the primary inputs provided by the user are the origin and the destination of the trip as well as the circumstances of the trip, implying the day of week, the time at which the trip begins, the time when the trip should end, or both. More specifically, routing algorithms require that the user enter in unique locations, in the form of land parcels, addresses, or landmarks, as origins and destinations. The GIS analysis must then deliver nearby bus stop identifiers to the routing algorithm. Finally, more sophisticated itinerary-planning tools ask the user for specific information such as how far they are willing to walk or drive to get to and from a transit stop, what preferences they may have for transfers, whether they prefer bus or rail modes, and whether they would like to minimize cost (fares) or travel time. While there has been substantial research on the design of interactive websites, of relevance here is the use of map information in this input process. Specifically, when designing the display of the system, consideration must be made to determine what cartographic information should be presented that is relevant to trip planning in specifying a trip origin and a trip destination. When deciding how users will determine the origin and destination bus stops, the developer must provide the options that the rider normally uses when planning a trip. Many people desiring to use transit either know the address of their origin or destination, or they know the name of a large landmark where they would like to leave from or go to. However, this does not constitute all of the ways that a transit rider would plan a trip. Many riders plan trips by looking at maps and identifying their approximate Journal of Public Transportation, Vol. 9, No. 2, 2006 50 location based on street intersections or other orientation landmarks. From that point, they decide which bus route to take. In attempting to provide this same level of information, many types of GIS-based cartographic information are available, including specific land parcels or locations (e.g., organized by street address), landmark data, and intermodal (transportation network) data. Landmark and intermodal data contain map features that would aid in the orientation of the users, as landmarks and street networks can be major inputs to the cognitive process of navigation. Landmarks show the user points of interest or large trip generators served by the transit network. Landmarks and the local street network can also aid the user in orienting themselves on the map. In addition, through the intermodal data, the user can also determine what modal options are available within or outside of the transit network. Overall, all features of the map must have some purpose that will aid the rider when determining the trip plan. GIS interfaces have the advantage of displaying different levels of detail and information depending on the scale or zoom level of the map. The primary challenge in designing the interface for user input is to determine how much information to display on the map. More cartographic information (e.g., additional landmarks, a background aerial photograph, a more detailed street network, etc.) may be very helpful to the user to assist in orientation and to find specific locations that serve as a trip origin and/or a trip destination. Conversely, more information can provide greater visual clutter, possibly confusing the user. In addition, more information in the display means that there can also be substantial latency in generating and manipulating the maps through a GIS-based system. As a result, a trade-off must be made in determining the type of information provided in the interface. Once the system has generated an itinerary, this information must then be presented to the user. Again from a cartographic perspective, the same map features for user input may also be useful for the map output. The display should also provide a clear indication of the recommended itinerary. Specifically, transit route(s) to be used can be accentuated by highlighting specific bus stop locations and paths of access from origin to bus stop and from bus stop to destination. Key Functions A GIS-based interface provides all of this functionality for identifying origin and destination bus stops: an address search function, a landmark search function, and a function that allows the user to click (or select) any point on the map, allowing Design of a Map-Based Transit Itinerary Planner 51 the user to select specific landmarks, specific locations, and/or individual land parcels (specific addresses). Figure 1 displays the core series of events that occurs when a user runs a mapbased itinerary planner, specifically over the Internet. With the GIS functionality, the user can have numerous options to select the trip origin and destination. If the user knows the address or landmark, they can enter that directly as a text field. The GIS system can then conduct a query for that location (feature) in the database. Once the feature is found, it can be highlighted on the map and a buffering tool in the GIS can be used to find all of the bus stops within the a given (maximum) walking or driving distance. Those bus stops are then sent to the routing algorithm. Figure 1. Flowchart of Events Required for the Trip Planner Journal of Public Transportation, Vol. 9, No. 2, 2006 52 If the user prefers, he/she can utilize the point-and-click capability of the GIS. With this function, the user can simply click a point on the map and the selected location is highlighted (and can even be displayed in text form). With this location, the system then identifies the same buffer around that parcel and the bus stops are sent to the routing algorithm. Essentially, manually inputing an address or landmark performs the same task as clicking a point on the map. All of the query tools access the same database for the location and generate a buffer around that location. The final critical input required by the routing algorithm is the desired time of departure from the origin, or the desired time of arrival at the destination. This information can be input by using a simple text form or pull-down menu. All of this information is sent to the routing algorithm, and the routing algorithm returns an itinerary to the viewer in the form of text directions and a highlighted route map. The main purpose of these functions is to provide an interface that can be accessed through a standard web browser, allowing everyone who has Internet access to use the system. It is also designed to provide all of the functionality of the system through a single, easy-to-use interface. As a design principle, all of this functionality can be provided by modifying the tools of existing GIS software to create a custom application. The adaptation of existing GIS tools is important in that many of the existing GIS resources that a transit agency may have can be applied directly to the system without the additional cost of accommodating a propriety system. Software and Data Requirements In a GIS-based itinerary system, spatial and temporal decisions are required and likewise, spatial and temporal data are required to make those decisions. The spatial data are usually stored as georeferenced shapefiles, covering the usual sets of shapes (points, lines, polylines, polygons, etc.) with associated database files. The temporal data required are schedule data for the bus stops. With these data, the GIS software, a routing algorithm, and itinerary planner can be developed. Software Based on the functions described in the previous section, the primary functions that might be considered internal to the GIS software tools include the ability to: Design of a Map-Based Transit Itinerary Planner 53 • generate maps for the World Wide Web (i.e., of reasonable size, electronically); • pan, zoom, refresh, and otherwise manipulate the map; • change display features based on the map scale; • select using point-and-click functionality on the map; • query for landmarks, addresses, and other points of interest; • generate buffers for determining passenger access and egress distances to and from bus stops; and • select and highlight portions of a route (bus route, street network, etc.) for display with the itinerary. In addition, the ability to generate a shortest path (itinerary) through the network can also be seen as a function that may be included directly in the GIS. Some commercial GIS software have this capability today. Spatial Data The spatial data used in the GIS can be categorized into three groups: those required for routing functionality, those complimenting an intermodal transportation network, and those landmarks that might aid in the use of the program. The basic routing functionality within the itinerary-planning problem requires bus route information, bus stop information, as well as a parcel layer that provides complete coverage of the transit network. The bus route information is used within the GIS to display available routes to the user when requesting input, and to display the recommended itinerary after it has been generated. The bus stop information is used to locate bus stops in the vicinity of the origin and destination (a set of parcels), typically using some sort of buffering function. Most GIS systems have a simple Euclidean distance buffer tool. More sophisticated buffering tools calculate distance along the street network, which is more appropriate for walking trips, but also more difficult to implement because the physical representation of access (existence of sidewalks, bicycle lanes, physical barriers, turning movements, etc.) requires a significant amount of additional data and computation. The intermodal data can be valuable to the user in determining potential access and egress routes, as well as providing a general spatial orientation to the map. Data in this category include the street network (at perhaps various levels of detail, such as major or minor streets, local roads, etc.), public parking lots or parkand-ride lots, transit centers, bike routes, walking paths, public trails, and other Journal of Public Transportation, Vol. 9, No. 2, 2006 54 such transportation facilities. Similarly, landmark information can include any number of possible forms to orient users to the map and to provide salient locations that serve as origins and destinations: major employment centers, shopping centers, schools, hospitals, parks, post offices, libraries, bodies of water, or other topographic features. The list of potential landmarks can be extensive. However, one is reminded of the potential trade-off between additional information for the user, and the creation of visual clutter, confusion, and longer computer processing times that might also be caused by the higher information display. Temporal Data The other major component of the trip-planning data is the temporal data, in the form of transit schedule data. Schedule information gives the departure time at each time point (and preferably every bus stop) along each route for each run (bus trip from terminal to terminal). Schedule data must be included for all operating schedules, such as weekday, Saturday, Sunday, and holiday schedules. In some cases, some routes or route segments are not operated on some days (e.g., express bus service is not operated on weekends); in these cases, separate data for routes and bus stops must be maintained, conditioned on the day of the week. In some instances, schedule data for specific bus stops is not available directly from the transit agency. In these cases, it is necessary to interpolate to determine the estimated bus departure times from these intermediate stops. This in and of itself can be done directly in the GIS, if a linear reference model has been created that gives the locations of bus stops and time points along a route. A less precise method simply uses the preceding time point when determining a passenger’s departure time from the origin, and the subsequent time point is used when determining a passenger’s arrival time at the destination. Prototype Design and Implementation Under these design principles, a prototype system was developed with commercial off-the-shelf GIS software and existing spatial and temporal data in Tucson, Arizona. This prototype system serves as a simple test of the functionality for Sun Tran, the fixed-route bus transit operator in Tucson. Developing a Custom Website The software used for this project was ArcIMS (Arc Internet Map Server) distributed by the Environmental Systems Research Institute (ESRI 2003). ArcIMS provides the functionality to present GIS information on the Internet or an intranet, Design of a Map-Based Transit Itinerary Planner 55 allowing users who do not have GIS software or who are not familiar with GIS operations to use the system. In addition, ArcIMS has all of the features described earlier in this article in terms of built-in functionality for producing a map-enabled itinerary-planning website. ArcIMS provides a simple interface with potential for customization that will allow both users and developers to easily use the system. To develop a website using ArcIMS, the developer must go through three stages of site development. The steps within ArcIMS are: 1. ArcIMS Author—develop an initial GIS map. 2. ArcIMS Administrator—create a map service using the map created in